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Abstract 

Previous efforts by the US Army Engineer Research and Development 
Center, Construction Engineering Research Laboratory (ERDC-CERL) to 
develop a life-cycle building model have resulted in the definition of a 
“core” building information model that contains general information de¬ 
scribing facility assets such as spaces and equipment. To describe how fa¬ 
cility assets (i.e., components) function together, information about as¬ 
semblies of assets and their connections must also be defined. The 
definitions of assets, assemblies, and connections for the various building- 
information domains are discipline-specific. 

The work documented here addresses the process flow and data exchange 
requirements for the design of water distribution systems in typical Army 
facilities. This ontology advances the state of the art by defining an Indus¬ 
try Foundation Class (IFC) Model View for water system design, support¬ 
ing end users in developing compliant BIM models, and suggesting poten¬ 
tial areas of automation in water system design. 


DISCLAIMER: The contents of this report are not to be used for advertising, publication, or promotional purposes. 
Citation of trade names does not constitute an official endorsement or approval of the use of such commercial products. 
All product names and trademarks cited are the property of their respective owners. The findings of this report are not to 
be construed as an official Department of the Army position unless so designated by other authorized documents. 

DESTROY THIS REPORT WHEN NO LONGER NEEDED. DO NOT RETURN IT TO THE ORIGINATOR. 
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1 Introduction 

1.1 Background 

Previous efforts by the US Army Engineer Research and Development 
Center, Construction Engineering Research Laboratory (ERDC-CERL) to 
develop a life-cycle building model have resulted in the definition of a 
“core” building information model that contains general information de¬ 
scribing facility assets such as spaces and equipment (East, Love, and 
Nisbet 2010). To describe how facility assets (i.e., components) function 
together, information about assemblies of assets and their connections 
must also be defined. The definitions of assets, assemblies, and connec¬ 
tions for the various building-information domains are discipline-specific. 
Taken together, studies of all essential building-information domains will 
create a unified framework for developing automatic design checks, ensur¬ 
ing construction compliance, improving operations and maintenance effi¬ 
ciency, and evaluating alternatives for redesign within completed facilities. 

COBie (East 2012a) was the first step in analyzing information exchanges 
in the life cycle of a building. Since March 2012, COBie has been part of 
the National BIM Standard-United States (NBIMS-US). COBie defines the 
format for providing information about building assets from the planning 
phase through design, construction, and operations. Properties of these 
assets may also be captured in the COBie date exchange format. The 
COBie Guide, a commentary on the COBie standard (public draft down¬ 
loadable at link from http://www.nibs.prg/?page=bsa cabieguide) . does not prescribe 
how to model specific assemblies of components or how components and 
assemblies are connected (East 2007, East 2012a). Those aspects of mod¬ 
eling and information exchange require a domain-specific ontology for 
every system needed to construct a functional building. 

The work documented here addresses the process flow and data exchange 
requirements for the design of water distribution systems in typical Army 
facilities. This ontology advances the state of the art by 

1. defining an Industry Foundation Class (IFC) Model View for water dis¬ 
tribution system design 

2. supporting end users in developing compliant BIM models 

3. suggesting potential areas of automation in water system design. 
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1.2 Objectives 

The objectives of the present work were to identify and document the re¬ 
quirements for building water distribution system design for the purpose 
of creating formal specifications that can be directly applied to open- 
standards building information models (BIM) at the coordinated design 
stage of building construction. 

1.3 Approach 

To document the process and exchange requirements, the team followed 
the Information Delivery Manual (IDM) and Model View Definition 
(MVD) procedures defined by the International Organization for Stand¬ 
ardization (ISO) and buildingSmart International (e.g., Wix 2007, 
Hietanen 2008). Validation of the process diagrams and exchange re¬ 
quirements followed the process outlined below: 

1. Create drafts of process diagrams and task descriptions for each of 
three phases of the design process—Criteria (i.e., Programming and 
Concept Design), Schematic Design (i.e., Design Development), and 
Coordinated Design (i.e., Construction Documents). The draft process 
diagrams included suggested steps for the typical Army design process, 
and the task descriptions included suggested information requirements 
needed to accomplish the task step. 

2. Assemble a group of subject matter experts (SMEs) to review and 
comment on the draft process diagrams and task descriptions. This 
group included three architects, two engineers, and two specifiers with 
experience in the design of interior plumbing systems. 

3. Meet with the SME reviewers to explain the process and review crite¬ 
ria. 

4. Send the process diagrams and task descriptions to the SMEs for their 
review. 

5. Analyze the SME comments and contact the SMEs for clarification and 
additional comments, as needed. 

6. Revise the process diagrams and task descriptions based on the SME 
comments. 

The specific selection and sequencing of tasks was intended as a starting 
point that would be refined using the SME reviewers’ feedback. The task 
forms included the information summarized in Table 1. 
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Table 1. Task form description. 


Item 

Description 

Task ID 

Sequential ID number for the task. 

Task Name 

A short descriptive name for the task 

Information Provider 
(Roles Involved) 

The role or roles that provide the input information 
necessary to do the task. 

Information Provider 
(Phase) 

The stage in the process when the required information 
is created. 

Actor (Roles Involved) 

The role or roles that complete the task. 

Actor (Phase) 

The stage in the process at which the task requires the 
information. 

Information Required 

The input information necessary to complete the task. 

Current Methods 

A short description of the task and its inputs and 
outputs. 


The experts were asked to review the tasks with the following questions in 
mind: 

• Do the task forms accurately and completely detail all information 
needed to perform the task? 

o If not, what is missing? 
o Who provides the additional inputs? 

• Are current methods of performing the task accurately described? 

For the process diagrams, the reviewers were asked: 

• Although every project has unique circumstances, are the tasks shown 
in the typically correct order? 

• Have we missed any tasks? 

• Are there any unnecessary tasks? 

• Are all tasks assigned to the correct phase(s)? 

• Are all tasks assigned to the correct actor? 

• Are all actors that provide the Information Required indicated? 

• Are any extraneous actors indicated? 


The SME reviewers are listed in Table 2. 
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Table 2. Subject matter experts. 


Name 

Organization 

Area of Expertise 

Joseph 0. Amos II, 

Assoc. AIA 

FKP Architects, Inc. 

Architect 

Omar H. Bailey, 

AIA, LEEDAP 

Bailey Edward Architecture 

Architect 

Architect with 13 years of experience. 

Darcie K. Kopischke 


Architect 

BArch degree from Iowa State University. Six years' work 
experience, primarily with JSSH Architects in 

Minnetonka, Minnesota, on projects varying from schools 
to multi-housing projects. 

Damon Cameron, EIT 
LEEDAP BD+C, CPD 

dbHMS 

Engineer 

Plumbing engineer with 6 years of Design Build and 
Consulting engineering experience with a commercial 
and healthcare focus, hands on construction experience, 
and experience implementing Revit MEP into design. 

Jim Forester 

Newforma, Inc. 

Engineer 

California P.E. license M24307. Co-Founder and Senior 
Technical Advisor at Newforma, Inc. Original member of 
the buildingSmart International Model Support Group. 
Involved with the many of the original definitions of the 
building services concepts and how they are connected, 
including the underlying graph representations 
supporting both symbolic and physical connectivity that 
would support mass and energy flow simulations. 

Mark Kalin FAIA FCSI LEED 

Kalin Associates 

Specifier 

Registered architect, CSI-certified construction specifier, 
LEED-accredited professional, and one of only 27 
individuals ever advanced to fellowship in both the 
American Institute of Architects and the Construction 
Specifications Institute. Author of numerous publications 
on specifications, product selection, and green specs, 
who has presented more than 100 sessions at regional 
and national conventions. He has taught architectural 
specifications at Harvard University Graduate School of 
Design and is currently chair of the Sustainable Facilities 
Practice Group of the Construction Specifications 

Institute. 
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Name 

Organization 

Area of Expertise 

Stuart Bailin 

Water Harvesting Solutions 

Specifier 

Director of Engineering for Water Harvesting Solutions 
(wahaso). Stuart has over 30 years of experience with 
the pumps, valves, tanks, instrumentation, controls and 
process designs used in water harvesting systems. He 
enjoys using his system design and CAD skills to create 
custom solutions for challenging client requirements. It 
is the close tie between client needs, process design and 
system build & install that ensure a project will work as 
specified. 


1.4 Scope 

The scope of the present work was to diagram the water distribution sys¬ 
tem design process, and to identify and document the relevant data ex¬ 
changes. A separate report (ERDC/CERL CR-13-5) applies this ontology to 
the updating of three previously developed experimental BIM models us¬ 
ing commercial off-the-shelf (COTS) software. Those models represent 
three types of typical low-rise Army facilities: a duplex apartment, an of¬ 
fice building, and a medical clinic. The experimental application work 
identifies some current product limitations in achieving successful infor¬ 
mation exchange. 

1.5 Mode of technology transfer 

Documentation of this ontology will be used as the basis for a ballot sub¬ 
mission to the National BIM Standard-United States. Model files created 
for the related validation application (ERDC/CERL CR-13-5) will be made 
publicly available for testing and evaluation of the proposed open BIM 
standard that results from this work. 
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2 Water System Design Process Models 

2.1 Overview 

Building design is a highly iterative process during which information is 
gathered, design options are evaluated and selections are made. The goal 
is to achieve a final design in which aesthetics, cost and systems perfor¬ 
mance are all optimized. During design, each choice has multiple effects. 
Optimized design can only be achieved through multiple iterations of in¬ 
terdependent analyses. 

Today’s designers and owners seek to optimize multiple aspects of a build¬ 
ing, including first cost, life cycle cost and environmental impact. Early 
adopters of building information modeling technology have demonstrated 
that the use of computable building models, coupled with the availability 
of analysis software, facilitates and reduces cycle times of the iterations 
necessary to achieve such optimization (Fallon and Palmer 2007). The 
purpose of this water systems ontology is to define a standardized com¬ 
putable description of all water system parameters necessary for a com¬ 
plete design. The availability of such a standardized, computable descrip¬ 
tion supports the development and use of water system design automation 
software. 

2.1.1 Water system design process 

The design of building water systems iterates through multiple steps, in¬ 
volving the provision of data by multiple parties and the repeated refine¬ 
ment of the design as it moves from generalized concepts and equipment 
types to detailed construction documents with the required equipment 
specified. 

The process diagrams in this document focus on the design tasks and data 
exchanges involving the Architect and Plumbing Engineer. Data required 
from other project participants are also documented. 

2.1.2 Water system design phases 

The water system design process is divided into three general phases, typi¬ 
cal of the Design-Bid-Build process for USACE projects. Although the se¬ 
quence of tasks and even the actors for each task can vary, depending on 
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project delivery approach and on the internal organization of the profes¬ 
sional services provider company(ies), the tasks that must be completed 
and the information required remain constant. 

2.1.2.1 Criteria (Programming and Concept Design) 

The Criteria phase requires gathering the necessary information that will 
define the project’s scope, budget, and overall goals. The Owner’s Project 
Requirements (OPR), building codes, site location, and sustainability goals 
are all indentified during this phase. Once the building program has been 
developed, the Facility Occupancy Model can be determined. This infor¬ 
mation allows the Architect and Plumbing Engineer to develop a Concept 
Design. Typically, several options are created to compare designs or sys¬ 
tem alternatives. 

2.1.2.2 Schematic design (Design Development) 

The Schematic Design phase requires using the information developed 
during the Criteria phase to develop the building design further. For water 
systems design, most of the information is generated by the Plumbing En¬ 
gineer. The Architect provides information regarding plumbing fixture 
counts, fixture locations and room sizes. Other consultants will provide 
water and waste requirements for other building systems. This infor¬ 
mation allows the Plumbing Engineer to determine the overall water de¬ 
mand. During this phase, specifications for the anticipated equipment are 
developed in addition to the drawings. The specifications identify perfor¬ 
mance requirements for the various plumbing system components. 

2.1.2.3 Coordinated design (Construction Documents) 

The Coordinated Design phase involves finalizing the documents in prepa¬ 
ration for bidding and construction. Primarily, this involves updating the 
drawings and specifications completed in the previous phases with more 
detailed, accurate information about the building and systems. Again, this 
requires that the Plumbing Engineer receive input from the Architect and 
any others involved whose particular discipline could have an impact on 
the plumbing system design. 

2.2 Specification of processes 

This section contains three Process Diagrams covering the water system 
design phases of (l) Criteria (Programming and Concept Design), (2) 
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Schematic Design (Design Development) and (3) Coordinated Design 
(Construction Documents). These phases have been assigned an arbitrary 
sequential number (10, 20, or 30) to aid in tracking and coordinating 
tasks. Following each of the three diagrams are tabular descriptions of the 
tasks shown in each diagram. 

The diagrams and task descriptions have been revised to reflect the re¬ 
views, and comments made by the SMEs in response to the draft process 
diagrams and task descriptions. Several of the reviewers suggested alter¬ 
native process flows, based on their experience with specific types of pro¬ 
jects and project delivery approaches — Design-Build versus Design-Bid- 
Build, for example. These suggestions were evaluated and, in some cases, 
the original flow was modified. Even where the workflow differed, howev¬ 
er, it was determined that the design tasks and information requirements 
remained the same. 

The solidification of the design involves an iterative process, where the 
owner, architect, the plumbing engineer and other specialists must recon¬ 
cile their needs with those of others. An explicit understanding of the pro¬ 
cess and its information requirements can help streamline the process by 
focusing on what exchanges take place and who is affected. It can also be 
used to help define new ways of reviewing multiple design options and in¬ 
tegrating them into the overall process. 

The detailed Exchange Requirements derived from the following task de¬ 
scriptions are described in the next chapter. 

2.2.1 Criteria Phase plumbing system design 

The Criteria Phase comprises the following tasks, shown diagrammatically 
in Figure 1. 
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Figure 1. Process diagram for Criteria Phase plumbing system design. 
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Task Form 

Task ID 

10 - T ask 

010 Name Develop Facility Occupancy Model 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Building Owner, Building Codes 

10 

Actor 

Architect 

10 

Information 

Required 

Owner’s Project Requirements 

■ Facility Type, Space Types, Area Standards, Occupant Load, Hours of 
Occupancy and design priorities 

Building Code Requirements 

■ Fixtures Per Occupant 

Site Location Information 

Current Meth¬ 
ods 

Architect receives document(s) from the Owner. Architect uses these docu¬ 
ments, in conjunction with Building Code guidelines and standards, to develop 
the Facility Occupancy Model. 


Task Form 

Task ID 

10 Task 

020 Name Compare System Options 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect, Building Codes, Utilities 

10 

Actor 

Plumbing Engineer 

10 

Information 

Required 

Facility Occupancy Load Requirements 

Performance Data 

■ Flow rate for fixtures 

■ Flow test 

■ Volume Per Visit 

■ Visits per Person per Period 

■ Minutes in Use 

■ Numbers of Users 

■ Efficiency Label 

■ Volume Per Day 

■ Input / Output Ratio 

■ Water Input Grade 

■ Water Output Grade 

■ Operating Pressure 

■ Distance to Source - Civil Plans 

■ Water Supply Fixture Unit (WSFU) 

■ Pressure Drop 

Building Heating Fuel Source 

■ Gas 

■ Fuel Oil 

System Budget 

■ Cost of System based on project type 

■ Cost of System based on anticipated water input 

Available Utilities and Rate Structures 

Current 

Methods 

Paper-based. Plumbing Engineer uses the Facility Occupancy Model, along with 
standard cost and performance information, to compare plumbing system options 
and recommend one or more plumbing system type(s) and a preliminary schedule 
of fixture types and counts. 



























ERDC/CERL CR-13-4 


11 


2.2.2 Schematic Design Phase plumbing system design 

The Schematic Design Phase comprises the following tasks, shown dia- 
grammatically in Figure 2. 


Figure 2. Process diagram for Schematic Design Phase plumbing system design. 
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Task Form 

Task ID 

20- 

010 

Use 

Case 

Name 

Locate Plumbing Fixtures 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

20 

Actor 

Architect 

20 

Information 

Required 

Water Supply Type(s) 

■ Cold Water 

■ Hot Water 

■ Grey Water 

■ Black Water 

■ Rainwater Harvesting 

■ Waste 

■ Specialty Waste 

■ Pure water 

■ Other liquid, gas, or fuel services 

■ Hot water fuel source 

Preliminary Schedule of Plumbing Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Foun¬ 
tain, Urinal 

Plumbing Fixture Counts 

Current Meth¬ 
ods 

Architect uses the recommendations and preliminary schedule from the Plumb¬ 
ing Engineer to indicate locations of the plumbing fixtures in the initial schematic 
plans. 


Task Form 

Task ID 

20” Task 

020 Name Propose Plumbing Equipment Requirements 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Water Supply Type(s) 

■ Cold Water 

■ Hot Water 

■ Grey Water 

■ Black Water 

■ Rainwater Harvesting 

■ Waste 

■ Specialty Waste 

■ Pure water 

■ Other liquid, gas, or fuel services 

■ Hot water fuel source 

Water and waste requirements from other building systems 

Plumbing Fixture Count 

Owner Equipment 

Plumbing Fixture Locations 

■ Plumbing Plan 

Current 

Methods 

Plumbing Engineer uses the information provided by the Architect on the plumbing 
system and other water and waste systems to develop one or more proposal(s) for 
plumbing equipment requirements. 

Plumbinq Engineer creates a Plumbing Equipment List. 
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Task Form 

Task ID 

20” Task 

030 Name Propose Plumbing Spatial Requirements 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Preliminary schedule of fixture types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Fountain, 
Urinal 

Plumbing equipment list/schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 

Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Plumbing Equipment Sizes 

Location of Fixture 

■ Plumbing Plan 

Current 

Methods 

Plumbing Engineer uses the Plumbing Equipment List and preliminary architectural 
plans to develop proposed Plumbing Space Requirements. 


Task Form 

Task ID 

20” Task 

040 Name Locate and Size Plumbing Equipment Room(s) 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

20 

Actor 

Architect 

20 

Information 

Required 

Plumbing Space Requirements 

■ Equipment Sizes 

■ Equipment Clearance requirements 

Current 

Methods 

Architect uses the proposed plumbing spatial requirements developed by the 
Plumbing Engineer to locate and size any needed plumbing equipment rooms in 
the schematic plans. 


Task Form 

Task ID 

2Q- Task 

050 Name Specify Plumbing System Performance 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Plumbing system type(s) 

■ White 

■ Grey 

■ Rainwater Harvesting 

Schedule of Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Foun¬ 
tain, Urinal 

Plumbing Equipment List/Schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 
Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Stor¬ 
age Tanks, Gutters, Downspouts 

Fixture Counts 

Current Meth¬ 
ods 

Plumbing Engineer uses the supplied information to calculate Plumbing System 
performance values and create a performance specification. 
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Task Form 

Task ID 

060 Name Size Plumbin 9 S y stem 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer, Architect 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Plumbing System performance specifications 

■ Pipe section: size, location, flow rate, and pressure drop 

■ Pipe fitting: size, location, connection type, and pressure drop 

Schedule of Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Fountain, 
Urinal 

Plumbing Equipment List/Schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 

Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Location of Fixture 

■ Plumbing Plan 

Updated requirements from other building systems. 

Current 

Methods 

Plumbing Engineer uses this information to size the elements of the Plumbing Sys¬ 
tem. 


Task Form 

Task ID 

20“ Task 

070 Name Develop Basis of Design 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Plumbing System performance specifications 

■ Pipe section: size, location, flow rate, and pressure drop 

■ Pipe fitting: size, location, connection type, and pressure drop 

Schedule of Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Fountain, 
Urinal 

Plumbing equipment list/schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 

Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Plumbing Equipment Sizes 

Current 

Methods 

Plumbing Engineer uses the supplied information to develop a Basis of Design for 
the Plumbing System. The Basis of Design is exemplar products with the correct 
capacities and performance characteristics. 
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Task Form 

Task ID 

20” Task 

080 Name Document Plumbing Design Schematic 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer, Architect 

20 

Actor 

Plumbing Engineer 

20 

Information 

Required 

Architectural plans showing equipment locations 

Plumbing Product Type Template - 

Plumbing System performance specifications 

■ Pipe section: size, location, flow rate, and pressure drop 

■ Pipe fitting: size, location, connection type, and pressure drop 

Plumbing equipment list/schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 
Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Plumbing Equipment Sizes 

Current 

Methods 

Plumbing Engineer creates updated plumbing drawings and schedules that illus¬ 
trate the Design Schematic plumbing layout. 


Task Form 

Task ID 

2D- Task 

090 Name Coordinate With Other Building Systems 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer, Other Disci¬ 
plines 

20 

Actor 

Architect 

20 

Information 

Required 

Plumbing schematic drawings and specifications: 

Plumbing plans showing equipment locations as well as pipe routing and connec¬ 
tivity 

Plumbing Product Type Template 

Plumbing System performance specifications 

■ Pipe section: size, location, flow rate, and pressure drop 

■ Pipe fitting: size, location, connection type, and pressure drop 

Schedule of Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Fountain, 
Urinal 

Plumbing equipment list/schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 
Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Plumbing Equipment Sizes 

Drawings from all other disciplines 

Size and location information for: 

■ Structural 

■ Mechanical 

■ Electrical 

■ Fire Protection 

Current 

Methods 

Plumbing Engineer sends the plumbing drawings to the Architect. Typically, piping 
runs are shown as a single line and may not be annotated as to elevation. Architect 
takes drawings from all disciplines and either visually compares them (by such 
means as a light table or computer overlays) or utilizes clash detection software to 
identify and resolve spatial conflicts between building systems. 
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2.2.3 Coordinated Design Phase plumbing system design 

The Coordinated Design Phase comprises the following tasks, shown dia- 
grammatically in Figure 3. 


Figure 3: Process diagram for Coordinated Design Phase plumbing system design. 
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Task Form 

Task ID 

qq_ Tssk 

010 Name Update Facility Spatial Configuration 



Participants 

Roles Involved 

Phase 

Information 

Provider 

All Design Disciplines 

20 

Actor 

Architect 

30 

Information 

Required 

Coordinated drawings from all other disciplines 

Size and location information for: 

■ Structural 

■ Mechanical 

■ Electrical 

■ Fire Protection 

■ Vendor Drawings and Cut sheets 

Current Meth¬ 
ods 

Architect revises the facility spatial configuration plans based on the results of 
the coordination that took place at the end of Design Schematic. 


Task Form 

Task ID 

30” Task 

020 Name Determine Water Supply Requirements 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect, Plumbing Engineer, Other 
disciplines 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Product Type Template: 

Plumbing System performance specifications 

■ Pipe section: size, location, flow rate, and pressure drop 

■ Pipe fitting: size, location, connection type, and pressure drop 

Schedule of Fixture Types 

■ Bath, Bidet, Toilet Tank, Water Closet, Shower, Sink, Drinking Fountain, 
Urinal 

Updated Plumbing equipment list/schedule 

■ Water Heater, Washing Machine, Sterilizer, Water Softener System, 

Grease Trap, Garbage Disposer, Pumps, Solar Heating System, Storage 
Tanks, Gutters, Downspouts 

Updated Plumbing Equipment Sizes 

Updated Location of Plumbing Fixtures & Equipment 

■ Plumbing Plan 

System Type 

■ Cold Water, Hot Water, Sanitary, Treated, Waste, Storm, Vent 

Updated water and waste requirements for other building systems 

Current 

Methods 

Plumbing Engineer uses the Product Type Template, updated plans and other- 
discipline information to determine total water supply requirements. 
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Task Form 

Task ID 

non TssK Calculate Water Balance 

030 Name 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Water Supply Requirements 

■ GPM for fixtures 

■ Volume Per Visit 

■ Visits per Person per Period 

■ Minutes in Use 

■ Numbers of Users 

■ Efficiency Label 

■ Volume Per Day 

■ Input / Output Ratio 

■ Water Input Grade 

■ Water Output Grade 

■ Operating Pressure 

■ Distance to Source 

■ Water Supply Fixture Unit (WSFU) 

Current 

Methods 

The Plumbing Engineer performs manual calculations to determine the potential 
demand and supply of grey water in a facility based on usage by all disciplines. 
Plumbing Engineer updates the Water Supply Requirements and listing of plumb¬ 
ing equipment types, sizes and locations, if needed. 


Task Form 

Task ID 

040 Name Create Piping Schematics 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer, Architect 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Updated facility spatial configuration 
■ Architectural Plan 

Current 

Methods 

The Plumbing Engineer revises riser diagram(s) of the plumbing system based on 
updated facility spatial configuration provided by the Architect. This is completed by 
referencing the 2-D plans provided and manually creating a 2-D elevation, generi- 
cally showing the entire piping system. The Plumbing Engineer creates or updates 
plumbing topology, plumbing equipment schedule, plumbing controls schedule and 
plumbing zone diagrams and forwards the drawings and schedules to the Architect. 




























ERDC/CERL CR-13-4 


19 


Task Form 

Task ID 

Qfl- Toc|( 

050 Name La V 0ut Plumbin 9 S y stem 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Updated Facility Spatial Configuration 

■ Architectural Plan 

Plumbing Zones 

Plumbing Controls 

Plumbing Topology 

■ Riser Diagram(s) 

Updated water and waste requirements for other building systems 

Current 

Methods 

The Plumbing Engineer creates updated plumbing layout drawings based on archi¬ 
tectural floor plans, the updated requirements of other building systems and previ¬ 
ously-created piping schematics. 


Task Form 

Task ID 

3Q- Task 

060 Name Update Piping and Equipment Sizes 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Updated Plumbing Layout 

Plumbing Plan(s) - Fixtures, Equipment, Pipe routing, distribution sources 

Current 

Methods 

Plumbing Engineer updates the schedules of piping and equipment sizes. 


Task Form 

Task ID 

30- Task 

070 Name Update Plumbing Spatial Requirements 

Owner 


Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Updated Plumbing Layout 

■ Plumbing Plan(s) - Fixtures, Equipment, Pipe routing, distribution sources 
Updated Piping and Equipment Sizes 

Current 

Methods 

Plumbing Engineer updates the spatial requirements for the needed plumbing 
equipment based on any architectural design changes. The Plumbing Engineer 
communicates any increases or reductions in plumbing spatial requirements to the 
Architect. 
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Task Form 

Task ID 

qq_ T as b 

080 Name Update Facility Spatial Configuration 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Plumbing Engineer 

30 

Actor 

Architect 

30 

Information 

Required 

Updated plumbing layout 

■ Plumbing Plan(s) - Fixtures, Equipment, Pipe routing, distribution sources 
Updated plumbing spatial requirements 

Current 

Methods 

Architect revises the facility spatial configuration plans based on the updated 
plumbing layout and spatial requirements provided by the Plumbing Engineer. 


Task Form 

Task ID 

3Q- Task 

090 Name Develop Product Specifications and Candidates 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect, Plumbing Engineer, 

Standard References 

30 

Actor 

Plumbing Engineer/Specifier 

30 

Information 

Required 

Updated piping and equipment sizing information 

Building Code Requirements 

■ Health & Safety requirements 

■ Fittings & Connection requirements 

Product research 

■ (3) Equal Product Type Candidate for each fixture / equipment component 

Current 

Methods 

On projects where the product specifications are performance-based rather than 
proprietary, and the project delivery method is design-bid-build, the Architect down¬ 
loads multiple manufacturers’ product information to compare properties of fixtures. 
Based on the fixture specification the Architect selects three (3) equal products and 
e-mails the manufacturers’ cut sheet information to the Plumbing Engineer or 
Specifier. The Plumbing Engineer or Specifier manually creates the 3-part specifi¬ 
cations based on information received. 


Task Form 

Task ID 

3Q- Task 

100 Name Document Plumbing Design Coordinated 



Participants 

Roles Involved 

Phase 

Information 

Provider 

Architect, Plumbing Engineer 

30 

Actor 

Plumbing Engineer 

30 

Information 

Required 

Updated facility spatial configuration 

Updated Plumbing Layout 

■ Plumbing Plan(s) - Fixtures, Equipment, Pipe routing, distribution sources 
Plumbing Topology 

■ Riser diagram(s) 

Plumbing Controls Schedule 

Calculations and Equipment Schedules/List 

Final Plumbing Specification 

■ Product Type Candidates 

Current 

Methods 

The Architect provides the building configuration, plumbing fixture locations types 
and counts on plan and elevation drawings. The Plumbing Engineer revises plumb¬ 
ing plans, riser diagrams, calculations and equipment schedules based on the ar¬ 
chitectural information. 
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Task Form 

Task ID 

Qf). Tgc|( 

110 Name Coordinate With Other Building Systems 



Participants 

Roles Involved 

Phase 

Information 

Provider 

All Design Disciplines 

30 

Actor 

Architect 

30 

Information 

Required 

Updated Plumbing drawings showing physical size and location of all elements in 
the plumbing system 

Final Plumbing Specifications 

Updated Drawings from all other Disciplines 

Current 

Methods 

Plumbing Engineer sends the plumbing drawings to the Architect. Typically, piping 
runs are shown as a single line and are mainly not annotated as to elevation. Archi¬ 
tect takes drawings from all disciplines and visually compares them (by such 
means as a light table, computer overlays or clash detection software in the case of 
a 3D model) to identify and resolve spatial conflicts between building systems. 
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3 Fundamental Concepts 

3.1 Overview 

This chapter documents common concepts of information modeling ap¬ 
plied to various object types found in data exchanges. Each individual con¬ 
cept template may also be referred to as a functional part, and describes a 
graph of object classes and attributes. Such templates are further refined 
at each applicable object class to indicate specific values or types that may 
be used. For a complete presentation of the MVD, including IFC instance 
diagrams and tables indicating how the concepts are used by entities for 
exchanges, see http://docs.buildingsmartalliance.org/MVD WSIE . 

For a complete presentation of the MVD, including IFC instance diagrams 
and tables indicating how the concepts are used by entities for exchanges, 
see http://docs.buildingsmartalliance.org/MVD SPARKIE . 

3.2 Concept templates 

Various concept templates have been introduced in this specification, and 
existing concept templates have been adapted from the IFC4 specification 
of BuildingSmart International f www.buiidingsmart-tech.orgl . 

NOTE: This specification is also available in HTML and MVDXMLform, 
where the online specification contains additional content including in¬ 
stantiation diagi'ams and exchange requirements tables. 

This specification consists of a schema defining data types, along with 
common concepts indicating use of data types for particular scenarios. 

This chapter defines such common concepts, which are applied at entities 
having specific use. Such concepts also form the basis of MVDs, which are 
supplementary specifications that adapt the scope and rules of this schema 
for targeted domains within the building industry. 

Each concept template defines a graph of entities and attributes, with con¬ 
straints and parameters set for particular attributes and instance types. 
Various entities within this schema reference such concept templates and 
adapt them for particular use according to parameters. For example, the 
'Ports' concept template defines distribution system connectivity for me- 
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chanical, electrical, and plumbing systems and a pipe segment defines an 
application of the 'Ports' concept, having one port as an inlet and another 
as an outlet. 

3.2.1 Roots 

All entities having semantic significance derive from IfcRoot, where in¬ 
stances are identifiable within a data set using a compressed globally 
unique identifier (IFC-GUID). This identifier must never change during 
the lifetime of an object, which allows data to be merged, versioned, or ref¬ 
erenced from other locations. 

Resource-level instances (not deriving from IfcRoot) do not have any iden¬ 
tity, such that two instances having identical state are considered equal. 
For example, if an object has coordinates described by an 
IfcCartesianPoint instance, another object with the same coordinates may 
have a separate instance of IfcCartesianPoint or share the same instance; 
such difference is a matter of data storage optimization and does not imply 
any semantic relationship. This also implies that non-rooted instances 
may only exist if referenced by at least one rooted instance through either 
a direct attribute or inverse attribute, or following a chain of attribute ref¬ 
erences on instances. 

The distinction between rooted and non-rooted (resource-level) entities 
achieves several goals: 

• File size may be reduced by interning (sharing) non-rooted data in¬ 
stances; 

• Database retrieval may be more efficient by storing non-rooted data 
local to rooted data instances; 

• Storage size may be reduced by avoiding IFC-GUID storage for items 
not requiring direct retrieval; 

• Comparisons of differences may be done at a higher level where the 
context of such change is apparent; 

• Implementations may treat non-rooted data instances as immutable 
for efficiency or simplified usage. 


3.2.1.1 Identity 

An object needs to be identifiable for accurate processing by both human 
and automated processes. Identification may be through several attributes 



ERDC/CERL CR-13-4 


24 


such as Identification, Name, Description or GUID. The GUID is com¬ 
pressed for the purpose of being exchanged within an IFC data set - the 
compressed GUID is referred to as "IFC-GUID". While the IFC-GUID is 
normally generated automatically and has to be persistent, the Identifica¬ 
tion may relate to other informal registers but should be unique within the 
set of objects of the same type. The Name and Description should allow 
any object to be identified in the context of the project or facility being 
modeled. 

Various objects may have additional identifications that may be human- 
readable and/or may be structured through classification association. 

Various file formats may use additional identifications of instances for se¬ 
rialization purposes; however there is no requirement or guarantee for 
such identifications to remain the same between revisions or across appli¬ 
cations. For example, the IFC-SPF file format lists each instance with a 64- 
bit integer that is unique within the particular file. 

3.2.2 Project 

All files contain a single IfcProject instance indicating overall context and 
a directory of objects contained within. 

3.2.3 Project Declaration 

The project provides a directory of objects contained within using declara¬ 
tion relationships. 

3.2.3.1 Object type definitions 

Declaration of object types, such as element types utilized by the element 
occurrences within this project, within the context of the project. 

3.2.3.2 Property set templates 

Declaration of property set templates, including the property templates 
that are used as property definitions. Such templates define the applicable 
properties, their names, descriptions, measure types and property type 
(single, enumerated, bounded list or table value). 
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3.2.3.3 Project units 

The project context includes the definition of the default units within the 
IFC data set. Default units are those units that apply: 

• To all geometric representation items within the geometric representa¬ 
tion contexts; 

• To all attributes with a defined datatype indicating a measure datatype; 

• To all properties and quantities with a defined datatype indicating a 
measure datatype and with no local unit definitions provided. 

3.2.3.4 Project context 

A project representation context indicates the coordinate system orienta¬ 
tion, direction of true north, precision, and other values that apply to all 
geometry within a project or project library. 

3.2.4 Actor 

An actor is a person or organization participating in a project. Actors may 
fulfill one or more roles such as engineers, contractors, manufacturers, 
building occupants, etc. 

3.2.4.1 Contact 

Contact information indicates roles and addresses of people and organiza¬ 
tions. 

3.2.5 Control 

A control is a directive to meet specified requirements such as for scope, 
time, and/or cost. 

3.2.5.1 Calendar 

Calendar information is used to filter other objects to indicate time periods 
during which the control applies. 

3.2.6 Product 

A product is an occurrence of a physical or virtual object with finite spatial 
extent. 
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3.2.6.1 Product placement 

Product occurrences can be placed in 3D space relative to where they are 
contained. Placement is defined by a relative position (X, Y, Z coordi¬ 
nates), a horizontal reference direction, and a vertical axis direction. At the 
outermost level, relative directions are defined according to representation 
context; for example, +X may point east, +Y may point north, and +Z may 
point up. 

Placement follows aggregation and containment relationships as follows: 

• At the outermost level, a site is globally positioned according to lati¬ 
tude, longitude, and elevation; 

• For spatial structures, positioning is relative to aggregation. For exam¬ 
ple, a site may aggregate multiple buildings, each building may aggre¬ 
gate multiple building stories, and each building story may aggregate 
multiple spaces; 

• For building elements, positioning is relative to the containing spatial 
structure. For example, a building story may contain slabs, walls, col¬ 
umns, and beams; 

• For aggregated parts, positioning is relative to aggregation. For exam¬ 
ple, a staircase may aggregate one or more stair flights; 

• For feature elements, positioning is relative to the affected building el¬ 
ement. For example, an opening element is positioned relative to the 
wall it voids, which in turn is positioned relative to a building story; 

• For fillings, positioning is relative to the filled opening. For example, a 
door is positioned relative to an opening which in turn is positioned 
relative to a wall; 

• For distribution ports, positioning is relative to the containing distribu¬ 
tion element. For example, an air terminal may have a port connection 
for a duct segment or fitting; 

• For distribution elements, positioning is relative to the containing spa¬ 
tial structure, however may be constrained by port connections. For 
example, an electrical junction box may fill an opening within a wall, 
and the junction box may contain ports for contained outlets or switch¬ 
es; the placement of such connected elements is constrained relative to 
connected port of the junction box. As another example, an air terminal 
may fill a ceiling covering which is placed relative to a space; the 
placement of a connecting duct fitting may be constrained relative to 
the air terminal. 
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If a containing spatial structure contains a grid, then placement may also 
be based relative to grid coordinates. 

3.2.6.2 Product representation 

The shape of products may be represented in multiple ways for different 
purposes. Each representation has a well-known string identifier and a 
particular representation context. There may be multiple representation 
contexts to describe a shape at various levels of detail. Most building ele¬ 
ments have a 'Body' representation which defines or approximates the 
physical shape and volume. In addition to physical building elements, 
non-physical elements may have representations such as spaces and open¬ 
ings. 

3.2.6.3 Axis geometry 

Elements following a path provide an 'Axis' representation indicating a 
line segment or any arbitrary open bounded curve. Examples of such ele¬ 
ments include walls, beams, columns, pipes, ducts, and cables. For ele¬ 
ments that have a material profile set association indicating cross-section, 
a 'Body' representation may be generated based on the axis curve and ma¬ 
terial profiles. Curve styles may indicate particular colors, line thicknesses, 
and dash patterns for 2D rendering. 

3.2.6.4 Footprint geometry 

Elements filling a boundary provide a 'Footprint' representation indicating 
a rectangle or any arbitrary set of outer and inner boundary curves. Exam¬ 
ples of such elements include slabs and spaces. For elements that have a 
material layer set association indicating material thicknesses, a 'Body' rep¬ 
resentation may be generated based on the footprint and material layers. 
Fill area styles may indicate particular colors, tiles, or hatching for 2D ren¬ 
dering. 

The representation identifier of the footprint geometric representation is: 

• IfcShapeRepresentation.Representationldentifier = 'Footprint' 
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3.2.6.5 Surface geometry 

Elements may have a 'Surface' representation describing the outer surface 
of the object. Such representation may be used for hit-testing objects hav¬ 
ing part composition such as framed walls. 

3.2.6.6 Body geometry 

Elements may have a 'Body' representation describing the volumetric 
shape of the object. Such representation may be used for 3D rendering or 
quantity take-off. Geometry may be based on boundary representations 
describing outer faces, primitives such as spheres or cones, swept solids 
such as profile extrusions or revolutions, Constructive Solid Geometry 
(CSG) such as clippings or subtractions of other shapes, or Non-Uniform 
Rational B-Spline (NURBS) geometry. Surface styles may indicate particu¬ 
lar colors, textures, and reflectance for 3D rendering. 

The representation identifier of the body representation is: 

• IfcShapeRepresentation.Representationldentifier = 'Body' 

3.2.6.1 Clearance geometry 

Elements requiring surrounding space for clearance provide a 'Clearance' 
representation. The reason for clearance space may be due to ventilation, 
maintenance, or other purpose. Examples of such elements include boilers 
and chillers. Such representation may be used for interference checks, 
where the 'Clearance' representation must not intersect with the 'Body' 
representation of other objects, though may intersect with the 'Clearance' 
representation of other objects. 

3.2.6.8 Site location 

The site location may be used to determine climate conditions and appli¬ 
cable building codes. 

3.2.6.9 Building location 

The building location may indicate the address as found on a map. 
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3.2.6.10 Building story elevation 

The building story elevation may be used to determine water pressure re¬ 
quirements and allowance for pumps to regulate pressure. 

3.2.7 Product type 

Product types define explicit product models or parametric product fami¬ 
lies, that may be instantiated in buildings. 

3.2.7.1 Product type representation 

Product types may have representations indicating shape representation 
for geometry, clearance, or other concepts. 

The shape representation attached to a type is defined using the relation¬ 
ship RepresentationMaps of data type IfcRepresentationMap. It provides 
the means to store several representation maps for different purposes. In 
order to utilize the representation map at each occurrence of the product 
type, the product occurrence has to use the concept 'Mapped Geometry'. 

NOTE See IfcProductType for further information and figures explaning 
the concepts 'Product Type Representation' and 'Mapped Geometry'. 

3.2.7.2 Body geometry 

The Body representation defines the physical shape of the product type. 

3.2.7.3 Clearance geometry 

For elements that require clearance such as for safety, maintenance, or 
other purpose, this represents the 3D clearance volume of the item having 
RepresentationType of 'Surface3D'. Such clearance region indicates space 
that should not intersect with the 'Body' representation of other elements, 
though may intersect with the 'Clearance' representation of other ele¬ 
ments. 

3.2.8 Resource 


A resource represents usage of something, having costs and environmental 
impacts. 
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3.2.8.1 Resource cost 

Resources can have associated costs indicating financial costs and envi¬ 
ronmental impacts incurred according to a specified base quantity. 

Each cost value may be defined using a constant amount or calculated ac¬ 
cording to specified formula. 

3.2.8.2 Resource quantity 

Resources may be defined according to a base quantity, where assigned 
tasks consume such amount of resource relative to an output quantity. 

For work-based resources such as labor and equipment, quantities are 
based on time. For product-based resources, quantities are based on 
count. For material-based resources, quantities are based on volume. 

3.2.9 3.2.8 Resource type 

A resource type represents a template of usage of something, having cost 
rates and environmental impact rates. 

3.2.9.1 Resource cost rate 

Resource cost rates are provided for anything that may be sold in quantity, 
such as product models that may be ordered, or common services that may 
be priced by unit. 

3.2.10 Association 

Association refers to relating objects to external information such as doc¬ 
uments, databases, and classifications. 

3.2.10.1 Classification 

Objects, type objects, properties, and some resource schema entities can 
be further described by associating references to external sources of in¬ 
formation. The source of information can be: 

• A classification system; 

• A dictionary server; 

• Any external catalogue that classifies the object further; 
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• A service that combine the above features. 

An individual item within the external source of information can be select¬ 
ed. It then applies the inherent meaning of the item to the object or prop¬ 
erty. 

3.2.10.2 Material 

Any product or product type can have associated materials indicating the 
physical composition of an object. Materials can have representations for 
surface styles indicating colors, textures, and light reflectance for 3D ren¬ 
dering. Materials can have representations for fill styles indicating colors, 
tiles, and hatch patterns for 2D rendering. Materials can have properties 
such as density, elasticity, thermal resistance, and others as defined in this 
specification. Materials can also be classified according to a referenced in¬ 
dustry standard. 

An object can be comprised of a single material or a set of materials with a 
particular layout. Several examples include: 

• A slab may have an associated layer of concrete; 

• A beam may have an associated I-Shape profile of steel; 

• A door may have associated constituents for framing and glazing; 

• A port may have an associated profile and/or material flowing through 
it such as hot water. 

EXAMPLE: Material information can also be given at object type, defining 
the common material data for all occurrences of the same type. It is then 
accessible by the inverse IsTypedBy relationship pointing via 
HasAssociations and via IfcRelAssociatesMaterial.RelatingMaterial to 
the material information. If both are given, then the material directly as¬ 
signed to object occurrence overrides the material assigned to object type. 

3.2.10.3 Material layer set usage 

Material layer set usage defines layout at occurrences to indicate a direc¬ 
tion and offset from the 'Axis' reference curve, and a reference extent such 
as for a default wall height. 
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3.2.10.4 Material profile set 

Material profile sets are associated with elements or element types where 
materials are placed in cross-sections of specified dimensions following a 
path defined at occurrences of the type. Examples of such products are 
beams, columns, members, reinforcing, footings, piles, pipe segments, 
duct segments, and cable segments. 

Material profile sets are associated by using the relationship 
IfcRelAssociatesMaterial having the RelatingMaterial pointing to an 
IfcMaterialProfileSet. The RelatedObjects either point to a single or multi¬ 
ple occurrences of IfcElement, or to a single or multiple IfcElementType. 

EXAMPLE: Material profile sets can be provides at the IfcColumnType, 
defining the common material information for all occurrences of the same 
column type. It is then accessible by the inverse IsTypedBy relationship at 
IfcColumn pointing to IfcColumnType having the HasAssociations inverse 
relationship to IfcRelAssociatesMaterial with RelatingMaterial refering to 
thelfcMaterialProfileSet. If an individual material association is provide at 
the IfcColumn and the IfcColumnType, then the material directly assigned 
to IfcColumn overrides the material assigned to IfcColumnType. 

3.2.10.5 Material profile set usage 

Material profile set usage defines layout at occurrences to indicate the off¬ 
set from the 'Axis' reference curve according to cardinal point, and a refer¬ 
ence extent such as for a default column height. 

3.2.10.6 Material constituents 

Material constituents are associated with products where materials are 
placed arbitrarily (unlike lD material profiles or 2D material layers). The 
mapping of materials to geometry may be accomplished using 
IfcShapeAspect. 

3.2.11 Definition 

Objects may be defined by having a number of properties, where such 
properties may be organized partially (into property sets) or fully (into 
templates). 
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3.2.11.1 Object typing 

Object occurrences can be defined by a particular object type, using the 
Object Typing concept. A pair of entities is defined for most semantic ob¬ 
jects - an object occurrence entity and a corresponding object type entity. 

EXAMPLE: The IfcTank is the object occurrence entity that has a corre¬ 
sponding IfcTankType being the object type entity. 

On instance level, an object occurrence instance may have: 

• Similar state as its object type instance by applying all characteristics 
defined at the type; 

• Overridden state for particular characteristics; 

• No defined object type instance. 

• Characteristics defined at the object type level may include: 

• Common naming and predefined type; 

• Common properties within a type driven property set; 

• Common geometry representations, applied as mapped representation 
to each occurrences; 

• Common material assignments (with exception of material set usages); 

• Common definition of a decomposition structure. 

Many object occurrence and object type entities have an attribute named 
PredefinedType consisting of a specific enumeration. Such predefined type 
essentially provides another level of inheritance to further differentiate ob¬ 
jects without the need for additional entities. Predefined types are not just 
informational; various rules apply such as applicable property sets, part 
composition, and distribution ports. 

EXAMPLE: For scenarios of object types having part compositions, such 
parts maybe reflected at object occurrences having separate state. For ex¬ 
ample, a wall type may define a particular arrangement of studs, a wall 
occurrence may reflect the same arrangement of studs, and studs within 
the wall occurrence may participate in specific relationships that do not 
exist at the type such as being connected to an electrical junction box. 

The object type is attached using the IfcRelDefinesByType objectified rela¬ 
tionship and is accessible by the IsTypedBy inverse attribute. Only a max¬ 
imum one, or zero, object types can define an object occurrence. If the ob- 
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ject type has aggregated elements, such objects are reflected at the object 
occurrence using the IfcRelDefinesByObject relationship. 

3.2.11.2 Property sets 

Any specialization of object can be related to multiple property set occur¬ 
rences. A property set contains multiple property occurrences. The data 
type of property occurrence are single value, enumerated value, bounded 
value, table value, reference value, list value, and combination of property 
occurrences. 

3.2.11.3 Property sets for types 

For object types, property sets are defined directly. 

3.2.11.4 Property sets for performance 

For performance history, properties are in the form of time series, for 
tracking data at points in time. 

3.2.11.5 Quantity sets 

Any specialization of object can be related to multiple quantity set occur¬ 
rences. A quantity set contains multiple quantity occurrences. The data 
type of quantity occurrence values are count, length, area, volume, weight, 
time, or a combination of quantities. Each quantity is defined by its name, 
value, and optionally a description and a formula. 

The quantity set is expressed by instances of IfcElementQuantity, where 
the Name attribute determines the common designator of the quantity set. 
This specification contains a number of predefined quantity sets, a tem¬ 
plate definition is provided for each of them. The name of the template has 
to be used as the value of the Name attribute. The MethodOfMeasurement 
attribute specifies the method, by which the values of the individual quan¬ 
tities are calculated. For the quantity set templates included in this specifi¬ 
cation, the value of MethodOfMeasurement shall be "BaseQuantities". 
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4 Model View Definition 

4.1 Overview 

This chapter documents use cases for exchanging information related to 
electrical disciplines for building design and construction. Industry Foun¬ 
dation Classes (IFC) is the international standard for exchanging Building 
Information Modeling (BIM) data, which defines hundreds of classes for 
common use in software, currently supported by approximately 150 appli¬ 
cations. A Model View Definition (MVD) defines a subset of the IFC sche¬ 
ma that is needed to satisfy one or many Exchange Requirements of the 
AEC industry. Together with the IFC schema subset, a set of implementa¬ 
tion instructions and validation rules, called MVD Concepts, are pub¬ 
lished. The electronic format to publish the concepts and associated rules 
is mvdXML. While IFC defines how building information can be repre¬ 
sented electronically in general, an MVD defines which information is re¬ 
quired for particular scenarios. 

4.2 Exchanges 

Information required at various stages of a building project is organized 
into Exchanges. Each exchange defines what information is required, op¬ 
tional, inapplicable, or restricted. Application software may support filter¬ 
ing data to be imported or exported for a particular exchange, and con¬ 
tracts for projects may refer to such exchanges to identify the scope and 
format of information required for delivery. 

4.2.1 Facility occupancy model 

4.2.1.1 Requirements 

The facility occupancy model describes the site location, owner's project 
requirements, and building requirements. 

The site location indicates the geographic location for determining climate 
information, and the legal address for determining the jurisdiction and 
applicable building codes. 
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The owner's project requirements consist of a facility type and a set of 
space types, each indicating occupancy loads, hours of occupancy, design 
priorities, and climate control requirements. 

4.2.1.2 Usage 

The IfcProject indicates overall context including default units. The 
IfcProject is aggregated by an IfcSite which indicates the geographic loca¬ 
tion and postal address. The IfcSite is aggregated by an IfcBuilding which 
indicates overall building requirements in the form of property sets. The 
IfcProject declares IfcOccupant instances (via IfcRelDeclares) for each 
class of building occupant which may correspond to a number of people as 
indicated within the Pset_ActorCommon property set. Each IfcOccupant 
may have IfcWorkCalendar assignments using IfcRelAssignsToActor. The 
IfcProject declares IfcWorkCalendar instances (via IfcRelDeclares) for 
each calendar of occupancy. Each IfcWorkCalendar may have IfcBuilding 
assignments using IfcRelAssignsToControl. 

Prototypes for required plumbing fixtures are indicated as resources using 
IfcConstmctionProductResource with IfcSanitaryTerminal assigned using 
IfcRelAssignsToResource. The sanitary terminal may represent an arbi¬ 
trary quantity (as indicated by the resource) and is not physically placed in 
a building and has no placement or representation at the early design 
stage. The resource is assigned to an IfcTask with PredefinedType of 
ATTENDANCE, where the task is assigned to an 
IfcSpatialStructureElement (typically the overall IfcBuilding at early de¬ 
sign or IfcBuildingStorey to track pressure differences). 

4.2.2 Compare system options 

4.2.2.1 Requirements 

Domestic water requirements are based on occupancy load requirements 
and performance data for equipment. 

The following information is captured for each class of fixture: 

• Flow rate 

• Flow test 

• Volume Per Visit 

• Visits per Person per Period 
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• Minutes in Use 

• Numbers of Users 

• Efficiency Label 

• Volume Per Day 

• Input / Output Ratio 

• Water Input Grade 

• Water Output Grade 

• Operating Pressure 

• Distance to Source - Civil Plans 

• Water Supply Fixture Unit (WSFU) 

• Pressure Drop 

The following information is captured for available systems that may pro¬ 
vide the energy source for water heating: 

• Gas 

• Oil 

• Electrical 

The following information is captured for water distribution systems: 

• Cost of System based on project type 

• Cost of System based on anticipated water input 

• The following information is captured for project cost control: 

• System Budget 

4.2.2.2 Usage 

Domestic water systems are described using IfcDistributionSystem having 
PredefinedType set to DOMESTICCOLDWATER. Each top-level system is 
declared on the IfcProject using IfcRelDeclares. Devices within each sys¬ 
tem (e.g., IfcSanitaryTerminal, IfcValve, IfcPump) are assigned using the 
IfcRelAssignsToGroup relationship, where property sets indicate flow re¬ 
quirements on devices. 

Each fixture prototype is indicated using IfcSanitaryTerminal and as¬ 
signed to an IfcConstructionProductResource as a placeholder for indicat¬ 
ing arbitrary requirements. Property sets indicate required flow character¬ 
istics. 
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Systems for available energy sources are indicated using 
IfcDistributionSystem having PredefinedType set to GAS, OIL, FUEL, or 
ELECTRICAL. 

Systems provided by utilities are assigned to the utility company using 
IfcRelAssignsToActor where an IfcActor identifies the IfcOrganization of 
the utility having an IfcActorRole set to the user-defined value of 
'UTILITY. Utility-level systems typically contain IfcPump and 
IfcFlowMeter elements. 

Each available service is indicated using IfcTaskType indicating a process 
model with PredefinedType set to OPERATION. Such process model may 
have nested recurring tasks (IfcTask) via IfcRelNests with time periods in¬ 
dicating when the service applies using IfcTaskTimeRecurring. Costs of 
each rate structure are indicated by IfcSubContractResourceType where 
BaseCosts contains one or more IfcCostValue instances. Each 
IfcSubContractResourceType is assigned to the IfcTaskType or nested 
IfcTask using the IfcRelAssignsToProcess relationship. The utility (repre¬ 
sented by IfcActor) is assigned to the subcontract resource type using the 
IfcRelAssignsToResource relationship. 

4.2.3 Locate plumbing fixtures 

4.2.3.1 Requirements 

A preliminary schedule of plumbing fixture types may be indicated: 

• Bath 

• Bidet 

• Toilet 

• Shower 

• Sink 

• Drinking Fountain 

• Urinal 

For each fixture type, system connections must be indicated including: 

• Cold Water 

• Hot Water 

• Grey Water 

• Black Water 
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• Rainwater Harvesting 

• Waste 

• Specialty Waste 

• Pure water 

• Other liquid, gas, or fuel services 

• Hot water fuel source 

4.2.3.2 Usage 

Each fixture type is indicated using IfcSanitaryTerminalType and declared 
within the IfcProject using the IfcRelDeclares relationship. Property sets 
may be defined on fixture types indicating product requirements. Ports on 
each fixture type are indicated using IfcDistributionPort and nested within 
each IfcSanitaryTerminalType using the IfcRelNests relationship. Each 
port must indicate flow direction, port type, and system type. 

Fixture occurrences are indicated using IfcSanitaryTerminal and maybe 
placed within an IfcSpatialStructureElement (typically IfcSpace) in the ini¬ 
tial schematic plans where geometric placement is optional (if not yet 
known). Fixture occurrences indicate types (either specific product model 
or parametric requirement model) using the IfcRelDefinesByType rela¬ 
tionship. Physical connectivity (such as to wall, floor, or cabinet) may be 
indicated using the IfcRelConnectsElements relationship. 

4.2.4 Plumbing equipment requirements 

4.2.4.1 Requirements 

Plumbing equipment is determined according to water quality and flow 
properties of allocated sanitary terminals. 

Valves are determined according to system transitions (such as from Do¬ 
mestic Cold Water to Irrigation) where backflow preventers or release 
valves may be required. While not every valve must be elaborated at this 
stage, those that significantly impact pressure (such as backflow prevent¬ 
ers) are required such that pumps may be sized appropriately. 

Pumps are determined according to required pressure at fixtures, place¬ 
ment elevations, and pressure drop throughout downstream piping, 
valves, filters, and pumps. 
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Water heaters and holding tanks are determined according to required 
temperature and consumption based on occupancy patterns, and heat loss 
throughout downstream piping. 

Water filtration equipment is determined according to required water 
quality at fixtures and incoming water quality from the water source (such 
as utility, community well, or private well). 

4.2A.2 Usage 

Valves are indicated using IfcValve, where the flow regulation characteris¬ 
tics are indicated on the outgoing IfcDistributionPort. Pumps are indicated 
using IfcPump, where the incoming and outgoing pressure are indicated 
on each IfcDistributionPort. Heaters are indicated using IfcBoiler, where 
the incoming and outgoing temperature are indicated on each 
IfcDistributionPort. Filteration equipment is indicated using IfcFilter of 
PredefinedType set to WATERFILTER. 

4.2.5 Plumbing spatial requirements 

4.2.5.1 Requirements 

Once space requirements have been determined, space locations and di¬ 
mensions are allocated, where they are then adjusted according to specific 
disciplines to fulfill more detailed requirements. 

4.2.5.2 Usage 

Each device is indicated using a subtype of IfcDistributionFlowElement 
where either the occurrence or defined type may indicate geometry. Fix¬ 
tures for drinking or sanitation are indicated using IfcSanitaryTerminal. 
Appliances such as clothes washers and dishwashers are indicated using 
IfcElectricAppliance. Pumps are indicated using IfcPump. Water heaters 
are indicated using IfcBoiler. Water filters are indicated using IfcFilter. 

4.2.6 Locate and size plumbing equipment rooms 

4.2.6.1 Requirements 

Equipment rooms may be sized according to clearance volumes of boilers, 
pumps, filters, and appliances. While the final sizes are not yet known at 
this stage (piping layout and thermodynamic analysis has not yet been 
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done), space allocation is only accurate according to the general equip¬ 
ment requirements. 

4.2.6.2 Usage 

Pumps are indicated using IfcPump. Water heaters are indicated using 
IfcBoiler. Water filters are indicated using IfcFilter. Appliances are indi¬ 
cated using IfcElectricAppliance. 

4.2.7 Specify plumbing system performance 

4.2.7.1 Requirements 

For this exchange, performance requirements are elaborated for every wa¬ 
ter terminal, which may be used to size the plumbing system. 

Each element requires the following at incoming water connections: 

• Pressure range 

• Volumetric flow range 

• Pipe diameter 

• Water quality 

• Temperature range 

• Environmental temperature range (such as exterior for freeze protec¬ 
tion) 

Each element requires the following at outgoing drainage connections: 

• Volumetric flow range 

• Pipe diameter 

4.2.7.2 Usage 

The IfcProject declares one or more IfcPerformanceHistory instances, 
where the lifecycle phase should be set to DESIGNDEVELOPMENT to in¬ 
dicate development-level estimation precision. Top-level 
IfcPerformanceHistory instances (typically one) refer to water usage at a 
main utility port, typically corresponding to that on the SINK side of an 
IfcFlowMeter water meter, where such IfcDistributionPort may be as¬ 
signed to the IfcPerformanceHistory via the IfcRelAssignsToControl rela¬ 
tionship. The IfcPerformanceHistory makes use of the 
Pset_DistributionPortPHistoryPipe property set for indicating water flow 
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rate at periods of time, where each IfcPropertyReferenceValue points to 
IfelrregularTimeSeries. 

4.2.8 Size plumbing system 

4.2.8.1 Requirements 

This exchange indicates required quantities and sizes of plumbing equip¬ 
ment (pumps, valves, boilers, filters) based on system performance. It 
does not account for particular piping layout, therefore calculated pressure 
drop is approximated based on elevation and nominal horizontal routing. 

4.2.8.2 Usage 

Property sets indicate flow characteristics at each IfcDistributionPort. 

4.2.9 Plumbing basis of design 

4.2.9.1 Requirements 

Document process model, constraints, formulas, and tables used for mak¬ 
ing decisions on plumbing design. 

• Water calculations showing required and designed flow rate, pressure, 
and temperature 

• Estimated water heater loading 

• Estimated water treatment loading 

• Estimated water pump loading 

• A projection/summation of the pump loads to justify the sizing of the 
pumps 

• Estimated water source loading 

• An economic analysis to justify the selection of utility water, communi¬ 
ty well, or private well (if in rural areas) 

4.2.9.2 Usage 

To indicate multiple scenarios within a project, each scenario is indicated 
using IfcWorkPlan declared on the IfcProject using the IfcRelDeclares re¬ 
lationship. Once a plan is approved for usage, it may be nested within an 
approved IfcProjectOrder. Such work plan may have a nested 
IfcPerformanceHistory record indicating projected energy usage, which 
may be nested into sub-components corresponding to subsystems. The 



ERDC/CERL CR-13-4 


43 


particular systems are indicated using IfcDistributionSystem and are as¬ 
signed to the IfcPerformanceHistory energy projection using the 
IfcRelAssignsToControl relationship. 

4.2.10 Document plumbing design schematic 

4.2.10.1 Requirements 

The plumbing design schematic indicates system connectivity among fix¬ 
tures and indicate pipe sizes, but does not indicate particular paths of 
pipes. 

4.2.10.2 Usage 

Each pipe connection is indicated using the IfcRelConnectsPorts relation¬ 
ship, where the RealizingElement attribute may be set to an 
IfcPipeSegment. The pipe segment does not have geometry, but does have 
cross-section information provided using IfcRelAssociatesMaterial and 
IfcMaterialProfileSetUsage. The pipe size may be determined from 
IfcCircleHollowProfileDef for circular sections or 
IfcArbitraryClosedProfileDef for other shapes. 

4.2.11 Coordinate with other building systems 

4.2.11.1 Requirements 

For coordination with other building systems, plans are created showing 
equipment locations as well as pipe routing and connectivity. Plumbing 
schedules for equipment, fixtures, and pipes are derived. 

4.2.11.2 Usage 

Equipment is indicated primarily by subtypes of IfcFlowTerminal, 
IfcFlowController, and IfcEnergyConversionDevice. Equipment specific to 
a space is placed within an IfcSpace, while equipment that serves multiple 
spaces is placed within an IfcBuildingStorey. Pipes connecting equipment 
are attached to ports (IfcDistributionPort) on each device using 
IfcRelConnectsPorts. 


Slabs, walls, coverings, openings, and system furnishings are included for 
coordination, as most fixtures and piping is anchored or embedded within 
such structures using the IfcRelConnectsElements relationship, where di- 
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mensions must be known for proper sizing and locating of pipes and/or 
sizing of enclosing structures. The anchoring of elements is significant, as 
it indicates construction precedence: for example, a sink connected to a 
floor covering implies the floor must be installed prior to the sink installa¬ 
tion, whereas direct connection to a slab implies otherwise. 

• IfcSlabStandardCase is used for slabs on grade where water and drain¬ 
age lines must be coordinated before pouring such slabs. 

• IfcSlabElementedCase is used for framed floor levels where piping is fit 
underneath and may be drilled after construction. 

• IfcWallStandardCase is used for concrete or CMU walls where piping is 
typically coordinated before forming such walls. 

• IfcWallElementedCase is used for framed walls where piping may be 
routed provided adequate clearance and structural support. 

• IfcCovering is used for drywall (of a wall or ceiling) or flooring where 
fixtures are commonly attached. 

• IfcSystemFurnitureElement is used for cabinetry where plumbing fix¬ 
tures are commonly attached. 

For scenarios where pipes must traverse through walls or slabs, the 
IfcRellnterferesElements relationship is used. It is recommended that 
software generate such relationships automatically wherever there is inter¬ 
ference, and the users responsible for each element approve of the solution 
for voiding or rerouting. 

4.2.12 Facility spatial configuration 

4 . 2 . 12.1 Requirements 

This exchange enables an architect to revise the facility spatial configura¬ 
tion plans based on the results of the coordination that took place at the 
end of Design Schematic. Required information includes: 

• Spatial Elements (Buildings, Levels, Spaces, etc.) 

• Building Elements (Walls, Slabs, Doors, Windows, etc.) 

• Distribution Elements (Electrical, HVAC, Plumbing, etc.) 

• Spatial Zones 

• Systems & Circuits 

• Connectivity (Space Boundaries, Ports, Connections, Interferences) 

• Actors & Assignments 
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4.2.12.2 Usage 

Project participants responsible for particular systems are indicated using 
IfcActor with assignments through IfcRelAssignsToActor. 

Interferences with other building elements are indicated using 
IfcRellnterferesElements, where priorities may be indicated at such inter¬ 
section. 

4.2.13 Water supply requirements 

4.2.13.1 Requirements 

In this exchange, a plumbing engineer uses the product type templates, 
updated plans, and other discipline information to determine total water 
supply requirements. For each plumbing fixture, compatible product types 
are selected for each product occurrence (or if required, three compatible 
product types are selected that are suitable). The project delivery method 
may require the owner's approval for final product selection. The total wa¬ 
ter supply requirements are calculated on each branch according to con¬ 
current design load. 

4.2.13.2 Usage 

For each plumbing device, the specified type or range of types is defined 
using IfcRelDefinesByType. Overall water supply requirements are estab¬ 
lished at property set on IfcDistributionSystem of type 
DOMESTICCOLDWATER. 

4.2.14 Calculate water balance 

4.2.14.1 Requirements 

Calculations are performed to determine the potential demand and supply 
of grey water in a facility based on usage by all disciplines. Water Supply 
Requirements are updated to reflect a revised listing of plumbing equip¬ 
ment types, sizes and locations, if needed. 

• Flow rate for fixtures (e.g., GPM gallons per minute) 

• Volume per Visit 

• Visits per Person per Period 

• Minutes in Use 
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• Numbers of Users 

• Efficiency Label 

• Volume per Day 

• Input / Output Ratio 

• Water Input Grade 

• Water Output Grade 

• Operating Pressure 

• Distance to Source 

• Water Supply Fixture Unit (WSFU) 

4 . 2 . 14.2 Usage 

For each plumbing device, the specified type or range of types is defined 
using IfcRelDefinesByType. Overall water supply requirements are estab¬ 
lished at property set on IfcDistributionSystem of type 
DOMESTICCOLDWATER. 

4.2.15 Piping schematic 

4.2.15.1 Requirements 

This exchange provides detailed information for connectivity and place¬ 
ment of pipes, including the following: 

• Sanitary Terminal: Location, Load, Controls 

• Valve: Location, Load 

• Pipe Segment: Location, Connections, Load, Length, Material (copper, 
PVC, etc.) 

All products may have defined types indicating Manufacturer, Model, and 
Specifications. Such types may also have assigned tasks and resources for 
procurement, where resource types indicate Supplier, Location, and Cost. 

4.2.15.2 Usage 

All plumbing devices are connected together via ports (IfcDistributionPort 
having PredefinedType of PIPE, where the relationship 
IfcRelConnectsPorts has RelatingPort set to the water source (having 
FlowDirection of SOURCE ) and RelatedPort set to the downstream con¬ 
nection (having FlowDirection of SINK). Product types are indicated via 
subtypes of IfcDistributionElementType. Costs rates for product types are 
indicated via subtypes of IfcConstructionResourceType assigned to 
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IfcTaskType assigned to the IfcDistributionElementType. The task type 
qualifies the scenario for which the cost applies. 

Pipes are indicated using IfcPipeSegment with IfcDistributionPort at each 
end indicating connectivity. Pipe materials are indicated using 
IfcRelAssociatesMaterial and IfcMaterialProfileSetUsage indicating mate¬ 
rial and cross-section. Pipe paths are indicated using the 'Axis' representa¬ 
tion consisting of a subtype of IfcBoundedCurve. 

4.2.16 Layout plumbing system 

4.2.16.1 Requirements 

Pipe segments and fittings are detailed in this exchange, with full geome¬ 
try and connectivity elaborated. 

4.2.16.2 Usage 

Each pipe is indicated using IfcPipeSegment and each transition is indi¬ 
cated using IfcPipeFitting. Pipe sizes are indicated at IfcPipeSegment us¬ 
ing IfcRelAssociatesMaterial and IfcMaterialProfileSetUsage. Connection 
sizes and types are indicated at IfcDistributionPort using 
IfcRelAssociatesMaterial and IfcMaterialProfileSetUsage. 

4.2.17 Piping and equipment sizes 

4.2.17.1 Requirements 

Based on final allocation of pipe routing, pipes and equipment sizes may 
be adjusted. 

4.2.17.2 Usage 

Pipe segments are indicated using IfcPipeSegment, where pipe size infor¬ 
mation is indicated via IfcRelAssociatesMaterial and 
IfcMaterialProfileSetUsage. Flow properties at each pipe are captured at 
IfcDistributionPort using property sets. 



ERDC/CERL CR-13-4 


48 


4.2.18 Product type specifications 

4.2.18.1 Requirements 

For this exchange, the engineer selects specific plumbing equipment mod¬ 
els (or an approved list from several manufacturers). 

4.2.18.2 Usage 

Plumbing equipment occurrences are indicated by various 
IfcDistributionElement subtypes, where the selected model is defined by 
IfcDistributionElementType defined using the IfcRelDefinesByType rela¬ 
tionship. To indicate multiple accepted models, the top-level model 
(IfcDistributionElementType) indicates an abstract template (not having a 
model defined via Pset_ManufacturerTypeInformation) and has candidate 
types assigned using IfcRelAssignsToProduct. Each candidate type has 
model information defined via the Pset_ManufacturerTypeInformation 
property set. 

4.2.19 Document coordinated design 

4.2.19.1 Requirements 

The coordinated design contains full detail for all plumbing devices and 
their placement and interaction with other services within the building. 

4.2.19.2 Usage 

Plumbing elements are defined using subtypes of IfcDistributionElement, 
with ObjectPlacement and Representation set for all instances. Water dis¬ 
tribution ports are indicated using IfcDistributionPort, where all ports of 
type PIPE must be connected. Unlike electrical ports that can simply not 
have a connection, an open pipe port indicates a leak in the system which 
must be terminated by a pipe fitting cap or other equipment. 

The coordinated design requires full 2 D ('Axis' and 'Footprint' representa¬ 
tions) and 3 D ('Body' representation) where IfcProduct must have its Rep¬ 
resentation include each. 
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5 Conclusions 

In developing MVDs, the challenge is to extract detailed information from 
industry experts yet find commonalities that could be applied generally 
across varying project delivery methods, participants, and localities. Dur¬ 
ing this project there were varying levels of input. Some experts would 
work within the assumptions of the preliminary structure, others would 
alter various steps, and some created new process diagrams from scratch. 
Each party had different project delivery methods. Therefore, dependen¬ 
cies were factored out by making each exchange role-based, not contract- 
based. Achieving this level of granularity required many more exchanges 
than traditionally used in IFC MVDs. For example, information sent to a 
utility for obtaining rate structures and connection information is one spe¬ 
cific exchange, rather than being lumped into a higher level category such 
as “early design.” The definition of role-based exchanges supports a variety 
of project delivery methods. Where possible, exchanges were aggregated 
into higher levels when appropriate. 

Once each exchange was defined, the specific information needed down to 
the attribute-level of detail was described, leveraging the existing scope of 
the IFC data model where possible. While most product geometry infor¬ 
mation was already well-defined within IFC version 2 x 3 and implemented 
by many vendors, there were many concepts that required some of the 
lesser-supported IFC data structures and some that required the expanded 
MEP scope in IFC version 4 to achieve adequate levels of detail. There 
were also many cases of data constructs already in possible in the IFC 
schema but never detailed in the documentation. While realizing that 
many of these concepts were not supported by existing COTS software, the 
MVD has been defined to allow partial compliance for now, but with al¬ 
lowances to later relax or replace some requirements after testing models 
produced by existing software. 

In detailing functional parts used within the model view, this project also 
contributed new concepts back to IFC 4 that appeared to have wider uses 
in other disciplines (as IFC 4 was not yet finalized at the time). For exam¬ 
ple, a functional part for generically mapping data to spreadsheets was 
formalized to support common tables such as lighting schedules, while al¬ 
so supporting other MVDs such as COBie; this functional part also in- 
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volved advancing the parametric capability of IFC with the ability to gener- 
ically reference object attributes. Similarly, as details on connections be¬ 
tween equipment were elaborated, such uses also made their way into ex¬ 
panded port specifications within IFC 4 . 

Once the MVD was complete, existing IFC files were tested with the 
mvdXML electronic validation format. Concepts that were supported by 
existing software and those that required new functionality were noted. 
There were some very basic limitations such as not capturing the physical 
building address, which is required for determining applicable codes and 
utilities, and more complex limitations such as detailing projected utility 
usage. In trying to find a balance that would encourage faster adoption by 
vendors, critical concepts were strongly enforced while others were relaxed 
by making certain attributes optional. 

Going forward, the IFC 4 release and supporting technology has provided 
for integrated MVDs where the IFC specification and all published MVDs 
will be made available online in an integrated form. This will enable devel¬ 
opers of IFC to instantly cross-reference usage of entities across multiple 
model views and to create templates to be defined once where they are re¬ 
used across model views. The supporting mvdXML technology provides 
for computer-interpretable validation, content filtering, sub-schema gen¬ 
eration, and data adaptation. This enables new IFC software vendors to 
support information models with a substantially lower barrier of entry, 
and enables established software vendors with full IFC support to handle 
new MVDs automatically without additional work. This MVD is one of the 
first to leverage the growing ecosystem of mvdXML and has influenced the 
future direction of IFC with the various supporting concepts. 
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